AlarmQuery Object
The AlarmQuery object is used to setup and execute alarm filtering queries for the CAS. The query accepts user-defined parameters and filters, and returns data group element information for the filtered alarms in XML format.
Within the calling script, the basic sequence of operations is as follows:
- Create the alarm filter object
- Set the time window and periodic update interval
- Set the site/services
- Set the filter
- Set the notification point
- Start alarm filtering
- Wait for query completion notification
- Retrieve a list of services/key information
- Retrieve individual alarm information
- Clear query results to prepare for a new query
The main query is defined by start and end times and a periodic run interval. A string of site services, separated by semicolons, can be defined for the service filter. The simplest example of a query would include start and end times, a service definition in the form Site.Service, and a blank filter string. The blank filter would be totally non-restrictive within the scope of the time window and service definition.
The query object works as an asynchronous thread so that a query can be initiated at one time, and the results obtained at a later time. Once the object starts the query engine, it will run continuously until the calling script cancels the filtering. The periodic update interval defines the interval at which the query engine will execute the search for new alarms.
Unlike the EventQuery object, however, this does not utilize a background query engine. Results can be retrieved without asking the engine whether it has completed. When the engine is polled, results are returned.
Once the automation object starts the query engines, it will run continuously until the calling script cancels the filtering. The periodic update interval defines the interval at which the query engine will refresh its cache with new alarms. For example, if the update interval is 60 seconds, then every 60 seconds the automation object will have the engine refresh its cached results.
Alternatively, the calling script can specify an update interval of zero, which will result in the query performing one single update of the cache. However, caution must be taken when specifying the run-once option: if the engines have not had time to query and populate their cache, then the run-once option might return zero results, which may be incorrect. It is recommended that the script sleep after initializing the filters and before running once.
The calling script can define a CVS tag which will contain a notification of when the queries have completed. This notification point can be used to trigger a script to process results. Resetting the notification point value is not handled by the automation object; it is the responsibility of the calling script. Alternatively, the calling script can directly query for results as long as it desires.
Once the query has produced results, the calling script can retrieve the number of alarms. A list of services (Site.Service) and database keys (dbKeys) that matched the query can be retrieved. The service and key information can be used to individually retrieve the complete alarm information in XML format.
Declare the object using the following code:
|
CreateObject("CxEventIf.AlarmQuery") |
Each documented method will assume you have declared the AlarmQuery object using the following code:
|
Dim AlarmQuery Set AlarmQuery = CreateObject("CxEventIf.AlarmQuery") |
More:


